# AI 时代新岗位 FDE 前线部署工程师

> 月薪 7 万的 AI 岗位，第一天上班却在车间贴二维码

你好，我是程序员鱼皮。

AI 时代，有些同学觉得写代码越来越无聊了。

以前写一个接口要折腾半天，现在把需求交给 AI，接杯水的功夫，它就把代码、注释和测试都生成好了。刚开始确实很爽，但时间一长，每天做的事情越来越像机械的流水线：复制需求、等待生成、检查错误、修改提交，几乎不用动脑子。

![](https://pic.yupi.icu/1/01_AI%E6%97%B6%E4%BB%A3%E5%86%99%E4%BB%A3%E7%A0%81%E5%8F%98%E6%88%90%E6%B5%81%E6%B0%B4%E7%BA%BF_compressed_v3.png)

有没有一种工作，既能继续做技术，又不用一直坐在工位上等需求？

有，而且最近两年在 AI 行业特别火，薪资也相当能打，它叫 FDE。

第一眼看到这个缩写，很多人会以为是 Frontend Developer Engineering，也就是前端开发工程师。但 FDE 的全称其实是 **Forward Deployed Engineer**，翻译过来叫「前线部署工程师」。

![](https://pic.yupi.icu/1/image-20260807155727082.png)

简单来说，很多企业想用 AI 提效，但连第一步该做什么都说不清楚。具体要解决什么问题、先从哪里切入、最终由谁来用，他们自己可能也没想明白。FDE 要做的，就是走进客户现场，把这些模糊的需求变成能上线、有人用的系统。

这篇文章我会用一个虚构的项目故事，带你走完 FDE 的一次完整交付过程。你会看到这份工作真实的样子，也能顺便学到几个对做 AI 应用非常有用的方法，比如怎么把模糊需求收敛成可验收的目标、怎么给 AI 建立评估集。



## 一、了解客户的真实目标

假设你刚入职一家 AI 公司，导师直接给你安排了第一个项目，客户是一家生产背带裤的服装厂。

项目开始前，导师带着你和销售同事一起去服装厂开会，工厂的生产负责人、维修主管、负责信息系统的同学都在场。

生产负责人说：我们想做一个 AI 报修助手，让工人报修更方便，维修记录也能保存下来。以后数据多了，最好还能预测机器什么时候会坏。

导师问：工厂现在有多少机器运行数据？

会议室突然安静下来。维修主管翻了翻手里的笔记本，有些尴尬地说：我们现在只有机器清单、纸质维修单和工作群里的聊天记录，温度、振动、运行时间这些数据，没有专门采集过。

没有这些历史数据，AI 就无法学习机器出故障前的变化规律，预测也就无从谈起。

于是导师给出了新的方案：先把报修流程理顺，让 AI 帮工人整理报修信息，同时把每次的故障描述和维修结果结构化地保存下来。这样既能解决眼前的效率问题，也能为以后做故障预测积累数据。

![](https://pic.yupi.icu/1/02_%25E5%25AE%25A2%25E6%2588%25B7%25E6%2583%25B3%25E5%2581%259A%25E6%2595%2585%25E9%259A%259C%25E9%25A2%2584%25E6%25B5%258B%25E4%25BD%2586%25E6%25B2%25A1%25E6%259C%2589%25E6%2595%25B0%25E6%258D%25AE_compressed_v3.png)

这一步就是 FDE 的第一项核心工作：**把不切实际的需求，拉回到当前数据和条件能支撑的范围内。**

客户往往会直接提出他们想要的最终效果，但作为技术方，你得判断这个效果现在能不能实现。做不到就要及时说清楚，并给出一个眼下能落地、又能为未来铺路的替代方案。

会议最后，负责信息系统的同学还补充了一个要求：报修语音和维修记录必须留在厂内服务器，新系统也不能直接改动原有的数据。

于是这次会议只确定了一个目标：先把报修流程做通，让工人报修更快、维修记录更完整。至于具体该怎么做，还得走进车间才能搞清楚。



## 二、进入现场调研

第二天，生产负责人安排 A 车间的吴师傅带你熟悉现场。吴师傅在这家工厂干了很多年，每天踩缝纫机比你敲键盘还熟练，机器声音稍微不对，他马上就能听出来。

你跟着吴师傅走了一遍完整的报修流程：

1. 机器出问题后，工人先给班组长打电话，班组长再联系维修人员。电话本身只要十几秒，但后面要反复转述故障情况
2. 维修人员到了现场，还得重新确认是哪台机器、什么时候开始出问题、具体是什么症状
3. 机器修好后，工人还要补填一张报修表。有的写在纸上，有的发在工作群里，还有人忙完就直接忘了记。下次遇到类似故障，维修人员很难从这些零散的记录里找到上次的处理方法

![](https://pic.yupi.icu/1/03b_%E6%97%A7%E6%8A%A5%E4%BF%AE%E6%B5%81%E7%A8%8B%E7%9A%84%E4%B8%89%E4%B8%AA%E5%8D%A1%E7%82%B9_compressed_v3.png)

看完流程，思路好像很清晰：工人对着手机说出问题，AI 自动整理成报修单，然后把工单推送给维修人员。等机器修好后，维修人员再通过语音或者快捷选项把处理结果记录下来。

整个流程看上去就 3 步，好像没什么难度。

然而随着和吴师傅的深入交流，你才发现事情没这么简单。

同一台机器，吴师傅叫它「三号机」，隔壁康师傅叫它「老平车」，工厂电脑里的正式名称却是「A 车间 03 号平缝机」。

如果 AI 连工人说的是哪台机器都搞不清楚，后面的一切都白搭。所以导师让你先把每台机器在工人口中的各种叫法都记录下来，搞清楚这些别名和正式编号之间的对应关系。

万万没想到，原本以为接到项目就该回去写代码，结果先站在车间里，拿本子记录机器外号。

![](https://pic.yupi.icu/pine/03-ai-%E6%9C%BA%E5%99%A8%E4%B8%89%E7%A7%8D%E5%8F%AB%E6%B3%95.png)

但正是这一步，让目标发生了重要的调整。

之前在会议室里客户想的是「AI 帮工人报修」，到了现场才发现，真正的卡点是信息从工人到维修人员之间的流转：工人说不清楚是哪台机器、故障信息反复转述会丢失、修完之后记录留不下来。

所以目标被改成了：工人只需要说清楚问题，AI 负责整理工单、补全信息，并帮助维修人员查找过去的相似记录。至于机器为什么坏、应该怎么修，仍然由维修人员来判断。

**这就是为什么 FDE 必须去现场。** 会议室里听到的是客户以为的问题，车间里看到的才是真正的问题。



## 三、确定可量化的验收标准

回到会议室，导师抛出了一个问题：两周以后，我们拿什么交付才算让客户满意？

你可能会说：把 AI 报修系统开发好，部署上去就行了吧？

但「部署上去」不是验收标准。客户不关心你部署了什么，他们关心的是工人报修有没有变快、维修记录有没有留下来。双方要提前约定好具体的数字，达到了才算交付成功。

于是你们翻了过去一周的报修记录，发现维修人员平均要花 6 分多钟才能收到完整的故障信息，而且机器修好后，留下处理结果的记录还不到一半。

根据这些数据，和客户约定了 4 个验收指标：

- 报修信息要在 2 分钟内送达维修人员，不能再把工单发错车间
- 至少 90% 的维修任务要留下完整记录
- 至少 80% 的试点工人要实际使用新流程
- AI 整理关键信息的准确率需要达到 90%，系统才能进入车间试用

![四个可量化的验收指标](https://pic.yupi.icu/1/04_%E5%9B%9B%E4%B8%AA%E5%8F%AF%E9%87%8F%E5%8C%96%E7%9A%84%E9%AA%8C%E6%94%B6%E6%8C%87%E6%A0%87_compressed_v1.png)

这套做法其实对我们自己做项目也很有启发。不管是接外包还是做自己的产品，如果目标只是「做出来」，你永远不知道什么时候算做好了。而一旦把目标变成具体的数字，方向和优先级立刻就清楚了。

标准确认后，你拉着吴师傅一起，先在安静的办公室里做了一轮测试。

吴师傅对着手机说：三号机最近一直咔咔响。

AI 一个字都没听错，但却把工单匹配到了 B 车间。原因很简单，两个车间都有一台叫「三号机」的机器。

AI 听懂了普通话，却没听懂这家工厂的「厂话」。

于是你放弃了让 AI 仅凭工人口头描述来判断机器的方案，改成在每台机器上贴二维码。这种做法在制造业其实很常见，很多工厂的设备管理系统都是靠扫码来定位机器的。工人先扫码确认是哪台机器，再描述故障。

你先和负责信息系统的同学核对好机器编号和位置，把每个二维码和对应的机器绑定之后，花了一整天在车间里一张张贴上去。

入职前你以为 FDE 的技术栈是前端、后端、数据和 AI。进厂后才发现，还得会贴二维码。

![](https://pic.yupi.icu/pine/04-ai-%E8%B9%B2%E8%B4%B4%E4%BA%8C%E7%BB%B4%E7%A0%81.png)

听起来有点搞笑，但这一步恰恰体现了 FDE 的价值：**当模型能力搞不定某个问题时，换个工程手段绕过去，往往比死磕模型更有效。**



## 四、建立评估集

扫码定位解决了「AI 搞不清是哪台机器」的问题之后，你觉得最大的障碍已经扫清了。

导师却不这么认为。他说：吴师傅说一句话，AI 碰巧答对了，这只能算跑通了一个 demo。想要真正达到交付标准，得拿几百条真实报修记录来测，看整体准确率够不够。

这种测试在 AI 行业里一般叫 **Evals**，可以理解成给 AI 准备一套固定的考题。每次调整提示词、模型或处理逻辑后，都用同一批案例重新跑一遍，看准确率有没有提高。

Evals 是 FDE 做 AI 项目时至关重要的一环。客户验收的时候不会只看你演示一两个案例，而是要看几百条真实数据跑出来的准确率到底是多少。

于是你和工厂的维修主管翻出了一摞过去一年的纸质报修单，不少纸张已经发黄，上面还沾着机油。工作群里的记录也很随意，有人写「针断了」，有人写「断针」，还有人只留下一句「跟上次一样」。

花了两天时间，才从这些材料里整理出 300 条真实案例。

不出所料，第一轮测试很快就翻车了。

办公室里能听清的话，到了车间可就不一定了。几百台缝纫机同时运转，背景噪音很大，AI 经常把「断线」听成「断电」，把「跳针」听成「掉针」。300 条测试跑完，只有 81% 的关键信息被正确提取出来，离 90% 的验收标准还差不少。

而且过去的维修记录也不好检索，同一种故障在不同工人口中有好几种说法，AI 搜不到真正相关的历史记录。

针对这些问题，你们做了几轮针对性的优化：先在语音识别环节增加降噪处理，然后补充了一套车间常用说法的纠错词典（比如把「断电」在设备上下文里自动纠正为「断线」），再把纸质维修单和群聊记录重新整理入库、统一术语。

重新跑完整套测试之后，准确率从 81% 提升到了 93%，达到了验收标准。

![评估集跑测试，准确率从 81% 优化到 93%](https://pic.yupi.icu/1/05_%E8%AF%84%E4%BC%B0%E9%9B%86%E8%B7%91%E6%B5%8B%E8%AF%95%E4%BB%8E81%25%E4%BC%98%E5%8C%96%E5%88%B093%25_compressed_v2.png)

这套评估集也不是用一次就扔掉的。系统真正上线以后，新出现的失败案例会持续补充进去，作为下一轮优化的依据。



## 五、现场试用和迭代

评估集跑通之后，系统进入了 A 车间试用。结果又翻车了。

虽然整体准确率已经到了 93%，但毕竟还有 7% 的情况 AI 会搞错。你不太放心，就在界面上加了一个确认表格，让工人说完问题后，还要逐项检查 AI 填好的机器名称、问题类型和发生时间，确认没问题再提交。

吴师傅在页面上滑了两屏之后问你：我本来打个电话十几秒就好，用你这玩意儿还要看很久表格？

客户原本想减少工人报修和填表的时间，你却因为怕 AI 出错，给工人多加了一堆要确认的选项。

导师了解情况后说：93% 的准确率已经超过验收标准了，为了防那 7% 的错误，你让 100% 的工人每次都多操作一整页表格，这笔账算不过来。不如让 AI 自己判断什么时候没把握，遇到拿不准的才追问一句，大多数情况直接提交就行。

![确认表格与 AI 主动追问的对比](https://pic.yupi.icu/1/06_%E7%A1%AE%E8%AE%A4%E8%A1%A8%E6%A0%BC%E4%B8%8EAI%E4%B8%BB%E5%8A%A8%E8%BF%BD%E9%97%AE%E7%9A%84%E5%AF%B9%E6%AF%94_compressed_v1.png)

这个思路其实很值得记住：**做 AI 产品时，不要为了兜住少数错误，让所有用户都付出额外成本。** 更好的做法是让 AI 自己识别不确定的场景，只在必要时打断用户。

改版之后，AI 只在没听清或缺少关键信息的时候才追问一句，维修人员修好机器后，也可以通过快捷选项或语音留下处理结果。

驻场试用期间，你和导师每隔两天就要向生产负责人和销售同事汇报进展。白天陪工人测试、收集反馈，晚上回去改系统、重新跑评估集。

不过协调各方比写代码费劲多了。生产负责人想尽快看到效果，负责信息系统的同学又担心新系统影响正常生产，一线工人不愿意增加操作步骤。这些不同方向的顾虑都要一件件处理清楚，系统才有机会真正用起来。



## 六、上线验收和交接

两周试点结束后，按照之前约定的指标逐项验收。

报修信息的送达时间从 6 分多钟缩短到了 2 分钟以内，没有再出现工单发错车间的情况，维修结果的完整记录率从不到一半提高到了 90% 以上，超过 80% 的试点工人开始使用新的报修流程。

![上线验收的数据前后对比](https://pic.yupi.icu/1/07b_%E4%B8%8A%E7%BA%BF%E9%AA%8C%E6%94%B6%E7%9A%84%E6%95%B0%E6%8D%AE%E5%89%8D%E5%90%8E%E5%AF%B9%E6%AF%94_compressed_v1.png)

达到验收标准后，生产负责人同意把系统推广到其他车间，销售同事也拿着验收结果，继续和客户沟通后续的合作。

但事情还没结束。系统推广到 B 车间的第二天，维修主管就打来电话。B 车间有几台特殊机型，工人描述故障时用的说法和 A 车间完全不一样，AI 又开始乱匹配了。

于是你当天赶到现场，补充了一批新的纠错规则，把失败案例加进评估集，重新跑通测试，B 车间的系统才算稳定下来。

FDE 不像普通外包交付完就撤，系统上线以后出了问题，你得第一时间赶到现场自己解决。

项目收尾的时候，导师让你把系统的配置方法和常见问题整理成文档，带着工厂负责信息系统的同学走了一遍日常维护流程。他说：FDE 不能让客户离了你就不会用，得让对方的团队自己能接手。

做完交接回到公司后，你们把这次项目里摸索出来的经验带回了产品团队，包括二维码绑定方案、车间噪音环境下的语音纠错方法、维修记录的结构化整理思路。产品经理觉得噪音环境下的语音处理能力可以做成通用模块，沉淀到产品里，让其他制造业客户也能直接用上。



## 七、FDE 这份工作适合你吗

走完这一整套流程，你应该能感受到 FDE 的完整工作闭环了：

1. 确认客户的真实目标，把不切实际的需求拉回到当前条件能支撑的范围
2. 跟着一线用户走完真实流程，找到藏在日常操作里的真正问题
3. 确定方案和可量化的验收指标
4. 开发系统、建立评估集，用真实数据验证效果
5. 进入现场试用，根据用户反馈反复修改，直到系统真正有人用
6. 把现场经验带回产品团队，让产品变得更好

![FDE 完整工作闭环六步](https://pic.yupi.icu/1/08_FDE%E5%AE%8C%E6%95%B4%E5%B7%A5%E4%BD%9C%E9%97%AD%E7%8E%AF%E5%85%AD%E6%AD%A5_compressed_v1.png)

不同公司的 FDE，具体工作差异挺大的。有的专注做技术交付，商务的事有专人负责；但在不少公司，FDE 还要参与售前阶段的技术评估，甚至帮客户发现新的 AI 落地场景来推动后续合作。有的 FDE 同时服务好几个客户，有的则驻在一家客户那里待上好几个月。

不过核心都一样，就是站在客户和技术之间，把模糊的问题变成能上线、有人用、能产生业务价值的系统。

**这份工作并不轻松，甚至可以说很有挑战性。**

OpenAI 当前的 FDE 岗位要求出差比例最高可达 50%，真实项目中可能要在客户现场待上几周甚至几个月。除了前后端和 AI 应用开发能力之外，还需要能拆解模糊问题、建立评估方法、处理企业级的系统接入和生产环境部署，更要能同时和客户的技术负责人、业务负责人以及一线员工顺畅沟通。



## 写在最后

如果你喜欢研究真实业务，愿意和不同行业的人打交道，也能亲手把系统做出来并看着它被用起来，做 FDE 会很有成就感。

如果你只想安静写代码，不愿意驻场出差或者处理模糊需求，FDE 可能并不适合你，踏踏实实学好 AI 编程和 AI 应用开发，同样能找到不错的方向。

不管你以后会不会做这个岗位，这篇文章里的几个方法都值得记住：先确认真实目标而不是照单接需求、把交付标准变成可量化的数字、用评估集而不是几个 demo 来验证 AI 的效果、不要为了兜住少数错误让所有用户买单。

**这些能力才是 AI 时代真正稀缺的东西**，因为它们恰好是 AI 现在还做不了的部分。